The traditional telecom network is a Public Switched Telephone Network (PSTN) based on Time Division Multiplex (TDM) circuit switching and mainly used to bear voice services. Along with the rapid increase of data services, it is more and more difficult for the traditional telecom network to provide enough bandwidth and deploy new services. In recent years, in order to meet the rising communication demands, the NGN whose core is an IP network has been rapidly developed and applied to fixed communications, mobile communications and the like, thereby providing abundant audio, data and image services.
FIG. 1 is a schematic diagram illustrating a structure of the conventional NGN. In FIG. 1, a softswitch controls a Media Gateway (MG) through H.248/Medium Gateway Control Protocol (MGCP) and the like. On the softswitch, such protocols as H.323/Bearer Independent Call Control (BICC)/Session Initiation Protocol (SIP) run as well. Signalling interactions are performed on the softswitch, while the MG performs resource allocation, e.g., the establishment of a service bearer, under the control of the softswitch.
In addition, in the packet network in FIG. 1, the IP packet network has gradually become a bearer network of the NGN. Generally, different operators have their own IP packet networks. Thus, there are a great number of interactions of IP packets between a mobile operating network, a fixed operating network, and a traditional Internet Service Provider (ISP) network. Additionally, there are also a great many of interactions of IP packets between different mobile operating networks, different fixed operating networks, and different ISP operating networks. In order to implement the interactions of various IP packets, i.e., inter-working, between IP domains, it is necessary to introduce appropriate device forms to solve such inter-working issues as the establishment of a bearer, encoding/decoding or packet format conversion, Network Address Translation (NAT) and its traversal, security, Quality of Service (QoS) and so on between IP domains. At present, neither a complete technique and a networking scheme nor real applications can realize the inter-working between IP domains, except that a few individual issues of IP inter-working have been solved.
FIG. 2 is a schematic diagram illustrating the networking of pure IP inter-working devices defined by the Europe Telecom Standard Institution (ETSI) in its TS102.333 protocol. Related standards of the ETSI defines functions which is implemented by using H.248 packet to control the MC by a gateway controller (i.e., a softswitch), which include: {circle around (1)} across-domain allocation of an IP end point, i.e., allocating a local IP end point and indicating which side's remote IP end point to inter-work with the local IP end point; {circle around (2)} filtering remote IP addresses and points generally by a pinhole firewall; {circle around (3)} IP packet label, that is, adding a suitable value, such as that of a Virtual Local Area Network (VLAN), Differentiated Service Code Point (DSCP), Multi-Protocol Label Switching (MPLS) and so on, to an IP packet; {circle around (4)} resources reservation; {circle around (5)} NAT control.
As shown in FIG. 2, after receiving a call signalling from a user terminal, the gateway controller instructs, through H.248 message, the MG to allocate two local IP end points, i.e., T1 and T2, and perform bidirectional topology connection inside the MG. Then, the gateway controller instructs the two local IP end points to respectively establish a bearer with remote end points in two IP domains, for example, T1 inter-works with the IP end point in the IP access network and T2 inter-works with the IP end point in the IP core network so as to implement the inter-working between IP domains. The information of the IP end point includes an IP address and port number.
As noted above, ETSI TS102.33 and other related protocols make it possible that the gateway controller contorts the MG to perform the establishment of a bearer, filtering of a remote address and port, NAT, resource reservation for media flows in each IP domain, however, security issues caused by a user terminal sending the call signalling directly to the softswitch have not been invloved. Since the address information of the softswitch has not been shielded from the user terminal, the softswitch can not be surely kept away from evil attacks.
On the other hand, the method for implementing encoding/decoding or packet format conversion of a service packet between heterogeneous operating networks has not been expressly defined in related protocols of the ETSI. Since network forms are different, the audio and video encoding/decoding modes which are used by heterogeneous operating networks to transmit voices and images over the IP network are generally different. For example, the fixed network operating networks usually adopt such audio encoding/decoding mode as G.711 and G.729, while 3G mobile network operating networks often adopt AMR encoding/decoding mode. It is impossible to implement inter-working of audio or video packages contained in IP packets between heterogeneous operating networks without appropriate encoding/decoding or packet format conversion.
In order to ensure the security of the softswitch, the address information of the softswitch is generally shielded from the user terminal by a Session Border Controller (SBC). FIG. 3 is a schematic diagram illustrating the networking of an SBC in the related art. In FIG. 3, the bidirectional dash-dotted line represents media flows, the bidirectional dashed line represents signalling flows, and the bidirectional real line represents the Internet data flows. The SBC usually supports call proxy functions of such protocols as SIP, H.323, MGCP and so on, and may be regarded as the softswitch by the user terminal. The registration and call messages of the user terminal are forwarded to the softswitch after the signalling processing of the SBC. For the softswitch, the SBC can be regarded as the user terminal. The request for calling a called terminal is forwarded to the called terminal by the softswitch after the signalling processing of the SBC.
The SBC obtains such information as address change and bandwidth requirement of this session via performing signalling processing for a message from the user terminal or the softswitch, and determines whether the media flows are allowed to pass through according to such information as the current network resource occupation, thereby protecting the network.
In FIG. 3, for example, in one session, various signallings will carry address information in the payload of a protocol message in an interaction stage and implement a message response according to the address information. Moreover, the address information and port information of media flow channel of this session are dynamic information which is negotiated and generated via signalling interactions and will be carried in the payload of the protocol message as well. Common NAF does not prform processing for the address information in these IP payloads, therefore, a service bearer can not be established correctly. The SBC device, however, analyses the contents of the protocol message and performs appropriate processing for the address information thereof, which assures the normal establishment of the bearer and implements correct traversal of IP service packets between the user terminal, the SBC, the softswitch, and the called terminal.
The SBC may implement signalling proxy functions of such protocols as SIP, H.323, MGCP and so on. However, since the SBC is located near the border of an access network, it provides poor support for a control protocol used by large gateways, such as H.284, In addition, such problems as encoding/decoding or packet format conversion of a service packet between heterogeneous operating networks is not considered in the SBC. As a result, in a networking application, it is still needed to employ other devices to implement the encoding/decoding or packet format conversion of a service packet in the IP payload.
As can be seen from the related art, each existing solution solves only individual problems of inter-working between IP domains, and a complete technique and networking solution has not been presented. In order to implement the inter-working between IP domains, it is needed to add extra devices which may solve the remained issues of inter-working between IP domains. In this way, on one hand, the complexity of networking and the investments for devices may be increased; on the other hand, the delay between devices may be brought in,